Conventional conferencing systems comprise a number of end-points communicating real-time video, audio and/or data streams over and between various networks such as WAN, LAN and circuit switched networks.
A number of conference systems residing at different sites may participate in the same conference, most often, through one or more MCU's (Multipoint Control Unit) performing i.a. switching functions to allow the audiovisual terminals to intercommunicate properly.
As videoconferencing involves various recourses and equipment simultaneously interoperating at different locations and capabilities, there is a need for the possibility to manage the resources involved both for scheduled and ad hoc conferences.
Conferencing systems are therefore often provided with a management tool. The management tool may i.a. include a resource scheduler, a monitor module and a routing module.
As early conferencing equipment was ISDN based, it has now started migrating to IP based terminals and infrastructure. IP-based equipment is often connected to a Local Area Network (LAN), which is protected by Firewalls and NAT installations. This introduces a new problem in connecting between management systems and the associated nodes and equipment. The management system might as well be operating from outside the LAN, meaning that communication towards the managed nodes and endpoints has to force through Firewalls and NAT's. This is a problem due to a most often strict policy for what is allowed to pass through a firewall. Conventionally, all communication sessions through a firewall have to be initiated from inside. This means that all requests initiated from a management system to a device located inside a LAN would be rejected by the firewall. In addition, the management system would not know the terminating IP address of the device as the NAT installation hides the actual addresses of the devices.
Thus, the equipment may be able to transmit their reports out to the administration tool if the firewall is configured to let these reports out, but the administrator would have difficulties configuring and otherwise administrating the equipment, as it is prevented from requesting devices behind the firewall.
Allowing the reports out through the firewall may cause other information leaking out that was not intended to.
Most IP equipment of prior art uses SNMP (Simple Network Management Protocol) for monitoring purposes. The equipment sends a trap to the management system when something happens using a UDP/IP packet to a specific port. The management system might then probe the equipment using another specified port. For this to work through a firewall, the SNMP ports must be opened. This poses a very high security risk because mostly all IP equipment has SNMP, and thus the entire network would be exposed to the outside. Also the security mechanisms of SNMP is rather weak and malicious parties might intercept the messages and pretend to be the management system and issue the same administrator commands as the management system and alter the equipment configurations.
Another problem is that SNMP uses a specific port for the management system to access the equipment, thus if the management system is outside the firewall and NAT is in use, only one of the equipment on the inside could be accessed as the firewall could only map one port to one address on the inside. A way to work around this is to make a tunnel through the firewall and a specific utility on the inside (proxy) that would redirect the connection to the equipment. However, this would require some special extension in the management system and quite a lot of configurations.